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Manufacturers reshape a generally accepted 
operating system to broaden its application 

In an attempt to broaden the applications for cp/m, 
several hardware manufacturers, including Cromemco, 

Inc., SD Systems and Mostek Corp., have molded a 
generally accepted jjlc operating system to their own 
use. Such support should improve the attitude of users 
toward p-c systems and, more importantly, result in 
higher productivity. These newer systems improve 
both the efficiency of the hardware and the productivity 
of the application progranuner, who does not have to 
write a special routine to perform a simple multiplica¬ 
tion or to get at the system clock. 

CP/M is a disk operating system designed to run on 
8080- or Z80-p,p-based p,cs. Originally developed by 
Digital Research, Pacific Grove, Calif., in the mid- 
1970s, cp/m was one of the first hardware-independent 
disk operating systems for |xcs, providing a plug for a 
previous market void. Before cp/m, a |jlc user had to 
rely on software supplied by the |xc’s manufacturer, 
which was often limited in quality and quantity and 
usually could not be transported to other manufactur¬ 
ers’ systems. As a result, users were virtually tied to a 
particular manufacturer’s products. CP/M freed users 
from dependence on vendor software and gave them 
access to a growing base of pre-written and tested 
application-software packages. 

No operating system is without its faults, however, 
and CP/M is no exception. The original cp/m, for 
example, was intended for use with single-density 
diskettes, thus restricting the use of double-sided and 
quad-density floppy- and hard-disk systems. Similarly, 

CP/M was designed for use with a printing terminal and 
did not easily accommodate CRT terminals. These 
deficiencies, many of which have been corrected in 
subsequent cp/m releases from Digital Research, 


spurred several ixc hardware and softwai’e vendors to 
create their own CP/M-compatible systems. These 
include l/os (or tsa/os) and Multi-os sold by InfoSoft 
Systems; CDOS sold by Cromemco; sdos and cosmos 
sold by SD Systems, Garland, Texas; and the newest 
system, m/os-80 sold by Mostek. All these systems can 
run CP/M application programs without change. Their 
operational syntax is easier to use and more forgiving 
than the original cp/m’s, and they offer better user file 
protection and system performance. CP/M-compatible 
systems differ from their progenitor, however, in that 
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(Lditors note: As this article suggests, Digital Research hasn't been 
standing by idly as hardware vendors developed CP/ADcompatible 
operating systems. The originators of the popular system have been 
improving on the product themselves, and will detail some of those 
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CP/M-compatible systems differ from 
their progenitor in that they are tailored 
to operate on a pre-defined set of 
hardware, yielding systems that 
perform better than the original CP/M 
but have less flexibility. 


they are tailored to operate on a pre-defined set of 
hardware, yielding systems that perform better than 
the original CP/m but have less flexibility. This article 
compares CP/M-compatible systems to CP/M to show how 
differences in memory and disk structure affect system 
performance. 

In CP/M-compatible systems, the basic memory 
structure is usually very similar to that of CP/M 
systems. The transient program area (tpa) must start 
at location lOO Hex (Fig. i). The system implied-run 
directive assumes this and loads all transient programs 
at that address. Those programs can subsequently 
move themselves to other ram locations to make room 
for other transient programs. 

Many transient programs, especially the newer 
compilers, require the maximum amount of tpa ram 
space (56K bytes) to function. As a result, they cannot 
work properly on smaller systems. To circumvent this 
problem, some older programs, such as Digital Re¬ 
search’s DDT and some basic interpreters, overlaid the 
console command processor (CCP). They could do this 
because they handled the operator-computer interface 
themselves. 

CP/M-compatible operating systems improve on this 
space-saving technique by allowing the CCP operator 
interface (OPi) to be made disk-resident at system- 


generation time or at operator request. This increases 
the amount of available memory space by about aiv 
bytes. 

Improvements in the system parameter area 

CP/M-compatible systems have also made improve¬ 
ments in the system parameter ai-ea (I'"ig. 2 ), wliich is 
used to store vectors and data required by user 
programs and the system itself. For example, starting 
at location 0 , the system that branches to the “warm 
boot” or restart vector (location 0 ) causes some cp/m 
systems to reread portions of the DOS from disk. 
m/os- 80 and several other CP/M-compatible systems do 
not need to perform this disk access unless the OPi 
(console processor) is overlaid. 

CP/M-compatible systems define a few areas (Fig. 2 ), 
such as locations 28H through 2FH, that were designat¬ 
ed as unused or undefined in the CP/M documentation. 
Also, m/os- 80 and several other emulators provide the 
user with another level of security by trapping jumps to 
locations that contain Hex ff bytes. This feature 
protects the user from programs that branch into 
non-allocated areas of ram. cp/m does not support this 
feature and would permit the user to call location 38, for 
example, using whatever random value has been placed 
there as an executable instruction. 

CP/M also does not support user interrupts. Most 
cp/m implementations disable interrupts upon entry, 
thus defeating the entire interrupt protocol set up by a 
user application. Virtually all CP/M-compatible systems 
can and often do use interrupts for a number of user 
and system functions. 

Disk structure and sector size 

CP/m’s disk structure is not very efficient or flexible. 
For example, the cp/m home-disk operation requires a 


HOW COMPATIBLE ARE CP/M-COMPATIBLE SYSTEMS? 


The CP/M-compatible systems dis¬ 
cussed in this article are not totally 
compatible with all versions of cp/m 
because of the ambiguity of cp/m 
documentation and the existence of 
variations from the documentation. 
For example, some application au¬ 
thors have replaced areas of cp/m 
code with code that Is more to their 
liking or better suited to their 
Individual application. The response 
by the creators of CP/M-compatible 
systems is to disclaim compatibility 
with such programs because it would 
be Impossible to maintain compatibili¬ 
ty with these rogue applications. 

Almost all cp/M-compatible sys¬ 
tems were originally conceived in 
response to shortcomings in earlier 
versions of cp/m (up to 1.4). The 
compatibility question was consider¬ 
ably less complex then because of the 
lack of movement by Digital Research 
and the resulting stagnancy of the 


“standard." CP/M-compatIble authors 
had several years to eliminate 
Incompatibilities and had at one point 
corrected virtually all known bugs. 

The arrival of cp/m 2.2, however, 
caused the compatibility question to 
rear its ugly head again. Because 
Digital Research chose to use a 
different means to achieve larger file 
sizes, those programs written for cp/m 
version 2.0 and later versions lost a 
level of compatibility with the emula¬ 
tive systems. The authors of the 
CP/M-compatible systems have en¬ 
hanced their systems to emulate the 
new CP/M functions, m/os-so, for 
example, supports all cp/m version 2 
calls except those that Digital 
Research has labeled as not required 
for use by application programmers, 
or those that conflict with m/os-80 
standards. 

The best solution to the compatibili¬ 

ty question is to address each 


problem as it arises. Mostek has done 
so by buying and testing as many 
application programs and systems 
support languages as possible. 
Mostek has found that all programs 
that work on cp/m version 1.4 now 
work on M/os-eo. Programs that are 
specifically designed to run on cp/m 
version 2.2 are few and generally 
include new versions of existing 
compilers. These are currently being 
tested with results yet to be 
determined. Customers who are 
worried about compatibility are en¬ 
couraged to let Mostek test their cp/m 
application under m/os-bo . 

As for programs written expressly 
for cp/M-compatible systems, many 
use system calls not contained in the 
standard cp/m. This prohibits their use 
on a normal cp/m system. For 
example, many programs written by 
Cromemco for use with cdos will not 
run on a non-coos system. 
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Location; 

^ Contents; 

0000-0002 . 

' • ..rii-.'- ■-'i‘ 

Warm boot entry point; reinitializes operating system and passes control from user to DOS. 

•^0003 

lOBYTE; S-bit switch to Indicate various levels of I/O device hierarchy. 

‘ 0004 

(Reserved) 

OOOS-0007 

Jump vector to BDOS; used by transient programs to request supervisor services. 

(0006-0007) 

Address portion of above vector; used to determine lowest address in memory ia.sed by DOB. 

0008-0027H 

Interrupt locations 1-8 (not supported in normal CP/M implementations); used by 
interrupt-driven routines as required in CP/M-compatlblo systems. 

(0028H-002FH) 

(Not mentioned in CP/M documentation.) Reserved for interrupt vectors in CP/M- 
compatible systems. 

0030H-0037H 

Interrupt location 6 (not supported in normal CP/M implementations); used by interrupt- 
driven routines as required in CP/M-compataible systems. 

0030H-0037H 

CP/M-compatible debugger breakpoint. 

0038H-003AH 

Illegal address trap (M/OS-80) or CP/M DDT debugger breakpoint. 

003BH-003FH 

(Not used—reserved.) 

0040H-004FH 

Scratch area reserved for DOS. 

0050H-005BH 

(Not used—reserved.) 

005CH-007CH 

File control block (FCB) formatting area. For use by transient (user) programs). 

007DH-007FH 

(Not used—reserved.) 

0080H-00FFH 

128-byte buffer; default area used by disk I/O and console command line upon entry to a 
transient program. 

————-- -—--J 


Fig. 2. Contents of page zero. 


long trip back to track two for a directoi'y search or 
update. CP/M operations are substantially hobbled by 
this structiire. 

In most CP/M implementations, disk sectors are 128 
bytes long (thus the i28-byte buffer area at location 
080H). In other versions, especially the higher density 
systems, the sector size can extend to 1024 bytes. In 
these higher density systems, the DOS performs special 
handling and deblocking of these sectors. Some new 
disk-controller boards handle this deblocking with 
built-in CPUS and buffers in a manner totally transpar- clusters assigned to more than one file, or files whose 
ent to the DOS. Although cp/m can be adapted to either clusters are overlaid by incoming data from another 
soft or hard sectoring, most systems using 8-in. file. Ordinarily there is little recourse if this happens, 
diskettes employ the soft-sectoring technique. There is Newer CP/M-compatible systems, however, like 

no real standard for sl/i-in. diskettes. M/os-80, provide more protection against such prob- 

The system allocates blocks (virtually synonymous lems. Unlike CP/M, M/os-80 makes a new bit map 
with sectors) in groups ofeight or more, called clusters, whenever a file is opened. This takes the .system an 
which usually have a length of 1024 (ik) bytes (128*8). additional moment to perform but provides tlie security 
A bit map of the used and unused clusters is kept in needed to protect valuable files. In addition, a user is 
memory for each disk drive and is re-initialized every not locked out when a write-protect error occurs in an 
time the system is warm booted (whenever the application. A user often can recover frotri disk ei-rors 
operator types control-c) or the system is restarted by correcting the problem and instructing the operat- 
upon power-up. The IK cluster-allocation scheme signif- ing system to continue despite the error, or to retry the 
icantly reduces the size of the bit map but requires that procedure. A user can defeat this process by changing 
a file s size be mod ik, that is, no file can be smaller diskettes after files have been opened, or in the middle 
than IK byte with additional increments of IK for larger of an application that does not expect the operator to 
. change disks. But the chances of a self-inflicted file 

Allocation of clusters is made as the user program wound are considerably lessened in m/os-80 and some 
demands them. When using cp/m, a serious problem other emulators. 

can occur if a user fails to type control-c after changing CP/M allocates the outer sectors of the system 

a diskette. Because the bit map in memory would not diskette (O-l) to the bootstrap program and operating- 
necessarily match the newly inserted diskette, the system-resident image—or at least a program that will 
system can allocate sectors that the bit map erroneous- give the system enough intelligence to load the DOS 
ly shows to be vacant. The result is a directory that has image. The full operating system is then loaded from 



Fig. 3. Disk structure allocation. 
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CP/M-compatible operating systems 
improve on the epuce-suviiig lochiiiquo 
by allowing the CCP operator interface 
to be made disk-resident at 
system-generation time or 
at operator request. 

the file named system.com. Then the operator int(‘r- 
face is loaded from a file called opi.COM. Because this 
file thrashing takes about lO sec., CP/M-compatible 
operating systems do not reload the resident image into 
memory when a warm boot (control-c) is performed, 
saving a user several seconds of waiting. In addition, 
because the DOS is not reloaded, a system disk need not 
be kept on the master drive at all times as in some cp/m 
implementations. 

. The system file directory, which starts at track two 
or block 52, contains the names and locations of files on 


tlie disks and, in tiie case of ciVM*compalibU; sysUjins, 
or CP/m version 2.n, it contains lile'Securily atlril)uU‘ 

biLn. 4’hcuH? allribitlo liiln (MiabU^ u uin*r lo murk a liU* an 
write-protected, read-protected, erase-proU!cU‘d or 
system (to make the file invisible to an operator). Sonu* 
multi-user systems also permit a user password or user 
number to be assigned to a file, adding another level of 
protection. 

Increasing file sizes 

cp/m version 1.4 systems limit a file to 256K bytes, 
minus the system boot and directory blocks, thus 240K 
bytes. CP/M-compatible systems increase the blocks- 
per-cluster to 16 or more to accommodate larger disks. 
This increases the cluster size to 2K and increases the 
minimum file size to 2K with 2K increments. Expanded 
clusters provide the user with files that can extend 
beyond 512K bytes. 

CP/M version 2.n provides for larger files by allowing 
as many as 512 logical file extents, where each logical 


Relative byte Purpose 

0 Entry type (not used by CP/M 1.4); disk specifier in CP/M 2.2 and CP/M-C. 

1-8 File name (left-justified, blank-filled). 

9-11 File extension. 

12-13 Current file extent; beginning at 1, extent is incremented by 1 for every 16 clusters added to 

file. Essentially, this is the FCB number. Byte 13 used for larger files in CP/M-compatible 
systems. 

14 CP/M-defined as for internal use. 

15 Record count; number of blocks written to file in current extent (0-80 Hex). 

16-31 Cluster allocation map; bytes contain the cluster numbers for each cluster assigned to this file. 

32 Next sequential record to be read; relative to top of file with first record = 0. 

33-35 Random record pointer (24-bit value) to permit fetching or writing records nonsoquontialiy 

anywhere in a file. 


Fig. 4. File control block (FCB) structure. 


j CP/M is one of the most widely used 
j operating systems for the 8O8O/Z8O in 
I existence. Although m/os- 80 , cdos 
and the other CP/M-compatible ope- 
j rating system vendors have not sold 
I as many copies as Digital Research 
i has of the original cp/m, they have 
provided healthy competition. Be¬ 
cause of that competition, Digital 
Research has improved its systems 
support and has made several 
important improvements to the cp/m 
package. In short, cp/M-compatible 
systems have helped to bolster the 
performance, features and stability of 
the entire “cp/m standard” concept. 

The future of cp/m or cp/m- 
compatlble systems is tied to the 
future of the processors on which they 
are designed to run—the 8O8O and 
Z80, As 16 -blt processors evolve, 
operating systems will evolve around 
them, and users will again choose one 


THE FUTURE OF CP/M 

system that best meets their needs. 
Some of these new processors may 
be able to emulate the 8O8O or Z80 
chips, and thus support cp/m. But, as 
was seen in the transition from the 
IBM 360 DOS to the IBM 370 OS/MFT, 
“antiquated” operating systems can 
quickly lose favor with customers 
who, for reasons ranging from vanity 
to performance demands, want to 
migrate to faster operating systems. 

However, 8O8O/Z8O systems are 
likely to be around for decades. As the 
technology gets cheaper, the tenden¬ 
cy to produce one large, powerful 
machine will be offset by the concept 
of having a dozen or a hundred small 
ones to share the work. In these 
multiprocessor systems, single or 
multiple sets of cp/m (or a derivative 
of it) could be preeminent. 

The future will also see the 
maturing of multitasking versions of 


CP/M that are already emerging. 
These include mp/m (Digital Re¬ 
search, Pacific Grove, Calif.), cosmos 
(SD Systems, Garland, Texas) and 
Multi-os (InfoSoft Inc., Westport, 
Conn.). These systems enable a 
processor to be shared among 
several competing tasks. These 
systems, however, do not take full 
advantage of the declining costs of 
8 -bit jxps by using dedicated proces¬ 
sors to handle the various tasks. 
Some systems do use slave proces¬ 
sors to perform smart console 
overhead and disk front-end process¬ 
ing. But this dispersal of system 
intelligence to sub-processors is 
about as far as most mass-produced 
multiprocessor systems have gone on 
the 0-bit level. These multiprocessor 
systems are expected to gain favor as 
time passes because they are 
cheaper to produce;. 
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Virtually all CP/M-compatiblo sysloms 
can and often do use interrupts for a 
number of user and system functions. 

extent contains 16K bytes of data, cp/m 2.0 is struc¬ 
tured, however, so that as much as 128K bytes of data 
are addressed by a single physical extent (correspond¬ 
ing to a single directory entry), maintaining compatibil¬ 
ity with previous versions. 

Additional schemes involving entirely new directory 
structures are now in place in the newer M/OS-80 and 
CDOS versions as well as in the newest cp/m version 2.2. 
In the case of m/os- 80 (hard-disk version) and cp/m 2 . 2 , 
these extended-directory allocation formulas expand 
the user file size to more than 64M bytes. These file 
sizes are intended for use on hai'd-disk versions where a 
considerably larger bit map is kept on the disk itself to 


conserve system ram spacer 

l^\\v way lo d<*lin<’al<* Hh'S is I la* I'ilr cnnli-al 

block (PCii). Althougli the KCii varies sonu'wlial iVam 
system to system because of eccentricities (jf the 
implementation, the basic format is unchanged (Fig. 4). 
Newer hard-disk systems have altered the formal to 
accommodate larger files, but virtually all cp/m systems 
will recognize the file structure of another. In addition, 
CP/M-compatible systems employ several unused bytes 
to define attribute bytes, user ids and expanded file 
sizes. 

There are several areas of inconsistency between 
CP/M and its emulative cousins (Fig. 4 ). For example, 
byte 14 is reserved by CP/m for internal use. In many 
implementations of CP/M, it is set by the DOS to some 
random value; in others it is set to zero. M/OS -80 and 
several other CP/M-compatible systems expect this 
number to be the secondary record count. This counter 
is used only when the record count in byte 15 exceeds 


Program name 

CP/M M/OS-80 

. r . , 

Function 

ASM 


8080 absolute assembler. 


COPY 

Image copy entire disk. 


DISKED 

Disk diagnostic. Read all sectors of disk requested. 

DDT 

(DDT) 

CP/M debugger. This program is PROM-based in M/OS-80 with many of the same 
functions. 


DSKDUMP 

Dump a disk or file by block for inspection or alteration. Permits alteration of any 
sector in any file including the diskette directory. 

DUMP 

DUMP 

Print files in Hex and ASCII format. 

ED 

EDIT 

Text editor. 


ERASE 

Conditionally erase files with operator prompting. 


FORMAT 

Initialize diskettes. 


GTOD 

Initialize or read system clock. 


LABEL 

Examine or alter disk labels. Alter directory or cluster size. 

LOAD 


Intel Hex file loader. Translates Intel Hex format into memory image. 


MBMTEST 

Test RAM memory. 

MOVCPM 


Generate a new CP/M system for a particular memory size. 

PIP 

XPER 

Transfer datasets to other datasets or devices. 


PRINT 

Print disk files. 


SPLIT 

Segment large files. 


SPOOL 

Initiate print spooler. Permits printing of files as a separate task while system is 
functioning elsewhere. 

STAT 

XSTAT 

Determine directory status. In CP/M» list files by size, show or alter lOBYTE 
assignments. List-size function performed by DIR (built-in function) in M/OS-80. 


STARTUP 

User-written auto-start program for custom systems. 


STARTUP.CMD 

User-written auto-start batch (submit) file. 


SXPER 

Similar to XFER but requires only one disk. 

SUBMIT 


Submit a command stream from disk. 

SYSGEN 

WRTSYS 

Write system image to tracks 0 and 1. M/OS-80 reads from either a file or the 
system area of any mounted disk and writes to a file or the system area of any 
disk, even in single-disk systems. 


XDIR 

Extended directory. Provides a sorted listing in multiple columns for CRTs. Entire 
directory is shown on the screen at once. 

XSUB 


Extended submit utility provided in CP/M 2.S versions. Permits programs run 



under SUBMIT to accept input data from files. 


Fig. 5. CP/M and M/OS‘80 utilities compared. 
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Call: 

Function or feature description 

30 

Set file attributes. Permits marking a file as x'ead-protect, eraso-protoct, etc. 

33-36 

Supports random I/O to files of more than 65M bytes, 

*130 

Set user control-C handling. This permits setting up a one-use system that cannot bo user- 
interrupted. 

132-133, 152-154 

Logical block I/O without regard to files. 

133 

Control printer spooling (not supported by CP/M In any version). 

136 

Chain to user program. Future versions will permit this call to support an overlay 
technique. 

137-138 

Built-in multiply and divide routines. 

140 

Eject disk. Useful on systems that have hardware facilities to control disk ejection. Can be 
set up to prohibit removal of disks from a system until the software permits it. 

142 

Set terminal functions. On some systems, permits a certain CBT protocol to be built into 
the system so that user programs can converse with an application-transparent terminal. 

143-146 

Set/read date and time. 

149 

Read disk label. Disks under M/OS-80 may be user-labeled. 

150 

Turn disk-drive motors off. Some implementations turn the motors off if the disks are not 
used after more than 15 sec. 

151 

159 

Set system bottom. When loading user RAM- (or ROM-) resident subroutines, the system 

RAM top may be altered to reflect the presence of these programs. 

Gets the disk assigned as master. In M/OS-80, one of the disks may be designated the 
master library disk. The disk is searched when searched-for files are unsatisfied on the 



current or requested disk. 


Fig. 6. Enhanced CP/M functions available with M/OS-80. 


255io(fFi 6). The result is that when listing the directory 
for some CP/M disks on M/os-80 systems, the size shown 
is extremely large. However, once copied under 
m/os-80, the fields are corrected. 

Basically, the new CP/M-compatible systems can read 
old cp/m format directories. Not all new-format directo¬ 
ry structures are inter-compatible, but this has not 
been a significant problem so far. The widest diver¬ 
gence in incompatibility lies in the structure of the 
various hard-disk implementations. Because virtually 
all of these are of the fixed-media type, and lack the 
ability to be removed and moved to another dissimilar 
system, the problem will not be significant until 
removable-media disks are more commonplace. 

A more serious problem that has hampered trans¬ 
porting disks between systems concerns double-sided 
diskettes. Because ibm set the standard for 8-in. 
diskette formats (3740 format), a problem arose when 
IBM changed the optionally oo or ff filler bytes to 
mandatory ff when using dual-density or dual-sided 
disks. This meant that single-sided, single-density 
diskettes created on new machines could not be read on 
older machines. Fortunately, new controller chips from 
Western Digital Corp. allow software to select the filler 
bytes to permit downward compatibility. M/os-80 in the 
dual-density, dual-sided mode allows comp>atibility. 

Almost all cp/m implementations include utility 
programs to manipulate system files, create new 
systems and system disks, examine file directories or 
perform other housekeeping functions. Some cp/m- 
compatible systems, such as M/os-80 have considerably 
more support programs than cp/m (Fig. 5 ). Many of 
these programs take full advantage of the additional 

MINI-MICRO SYSTEMS/August 1981 


system calls provided by m/os-so. Others are similar to 
programs provided by CP/m, but, in most cases, provide 
more features and flexibility than their cp/m equiva¬ 
lents. It would be impossible to determine what 
features cp/m 2.2 would have at this time if it were not 
for constant competition by CP/M-compatible systems. 

M/OS-80, CDOS and other CP/M-compatible operating 
systems are intended to run on hardware of the 
manufacturer’s choosing, enabling vendors to increase 
system efficiency and reduce system memory require¬ 
ments. 

But pre-packaged systems do not address the 
problem faced by system configurators who want to 
create systems'around a custom card or a special 
front-end software handler. To alleviate this problem, 
Mostek is building a system that allows a user to write 
his own drivers and link them into the system as 
required. This method is considerably cleaner than the 
method used by Digital Research in the earlier versions 
of CP/M, which did not allow a user to boot up a 
hardware configuration different from the system on 
the boot disk. 

In addition to supporting standard cp/m functions, 
CP/M-compatible systems provide additional features 
that enable systems and applications programmers to 
use system resources more efficiently (Fig. 6). For 
example, a system spool operation enables a system to 
use the abundant wait time during periods of i/o to 
spool print files onto disks for later printing. Qj 


William R. Vaughn is an applications engineer with 
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